The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Software applications operating in a network environment produce or consume application messages. For example, a client software element hosted at an end station device such as a personal computer or workstation may form and send a message to a corresponding application server that is hosted in a network. Each message typically comprises one or more headers and a payload that contains application-specific information. Messages may be contained in more than one data frame, packet, segment, or other unit of organization under a network communication protocol. In the description herein, a “message” is a set of data relating to an application and associated with Layer 5, 6 or 7 of the OSI network reference model.
Such application-layer messages often need to be changed or transformed so that applications consuming the messages can handle them. These messages can arrive at a network device over different lower-layer protocols, such as HTTP, HTTPS, JMS, MQ, RV, and certain proprietary protocols that use TCP or UDP as a transport. Typically, a receiving application must receive a message in a particular format that the application understands. As a result, some intermediary processing unit must transform an inbound message to the required format for the application.
Generally, in past approaches such transformations have been performed using applications or mechanisms that are running on a host associated with an application endpoint. For example, an application server may include transformation logic. But as applications and their message formats evolve, each sending and receiving application is required to accommodate an increasing number of different application-layer message formats. The transformation logic at each application server requires modification to accommodate new formats. This is time-consuming and requires significant resources in programming labor. There is a need for an improved approach for performing application-layer transformation that does not require re-coding or modifying application servers, clients, or other end stations.
Further, in typical past approaches, application message transformation is performed either by an application consuming the message, or by a process or mechanisms running on a host on behalf of the application consuming the message. Alternatively, message transformation is performed by the application producing the message, based on the target application endpoint.
In all these cases, the number of points at which transformation is performed increases based on the number of application endpoints producing or consuming the message. For example, if seven instances of a database application were hosted in a particular server, then in the conventional approach, all seven instances would have to perform message payload transformation. This is a waste of application processing resources. There is a need for a more efficient approach that can somehow consolidate, at a single processing point, all message payload transformation work for a plurality of instances of an application or for multiple different applications.
One approach for performing message transformation is described in prior application Ser. No. 10/991,792, filed Nov. 17, 2004, of Pravin Singhal et al. (“Singhal et al.”), and assigned to the assignee hereof. The approach of Singhal et al. provides mechanisms for transport protocol message brokering. For example, the approach of Singhal et al. can receive a message that uses the HTTP protocol and change that message into an MQ message. However, the approach of Singhal et al. does not change, modify or transform data contained within a payload portion of the inbound message. Thus, if an inbound HTTP message contains an XML document as a payload, but a receiving application requires a particular kind of FIX or COBOL CopyBook message payload as input, the approach of Singhal does not provide a solution. In contrast, Singhal et al. would be able to change the inbound HTTP message into an IBM MQ message carrying the same XML document as a payload.
Further, if the inbound message has an XML payload containing a “date” data field that is expressed in “MMDDYY” format, but the receiving application requires all dates to be expressed in “YYYYMMDD” format, the approach of Singhal does not provide a solution.
Thus, based on the clear deficiencies of past approaches, there is a need for an approach that can perform message payload transformation independent of the application transport protocols that carry such payloads.